<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Compiling Bochs</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Bochs User Manual"
HREF="index.html"><LINK
REL="UP"
TITLE="Installation"
HREF="installation.html"><LINK
REL="PREVIOUS"
TITLE="Installing a Binary"
HREF="install-binary.html"><LINK
REL="NEXT"
TITLE="Setup"
HREF="setup.html"></HEAD
><BODY
CLASS="SECTION"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Bochs User Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="install-binary.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. Installation</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="setup.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECTION"
><H1
CLASS="SECTION"
><A
NAME="COMPILING"
>3.4. Compiling Bochs</A
></H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN911"
>3.4.1. Standard Compile</A
></H2
><P
>Bochs is written in C++, so you need a C++ compiler on your system.  Most
platforms have been tested with GNU gcc/g++, but other compilers are known
to work too.  By now, you should have unpacked your source TAR file or checked
out Bochs from SVN.  If not, you can return to <A
HREF="installation.html#DOWNLOADING"
>Downloading Bochs</A
> for details.  The top level
directory of the source code will be referred to as <CODE
CLASS="VARNAME"
>$BOCHS</CODE
>.  (<CODE
CLASS="VARNAME"
>$BOCHS</CODE
>
contains the files <TT
CLASS="FILENAME"
>bochs.h</TT
> and
<TT
CLASS="FILENAME"
>main.cc</TT
> and subdirectories <TT
CLASS="FILENAME"
>cpu</TT
> and
<TT
CLASS="FILENAME"
>bios</TT
>.)</P
><P
>The standard compile process has three basic steps:
<B
CLASS="COMMAND"
>configure</B
>, <B
CLASS="COMMAND"
>make</B
>, and <B
CLASS="COMMAND"
>make
install</B
>.  Each step is described in a separate section below.  The
standard compile process is used on all Unix machines, MacOS X, and
Cygwin (win32).  There are separate instructions for <A
HREF="compiling.html#COMPILING-WIN32"
>compiling for Win32 with Microsoft VC++</A
>.</P
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="CONFIGURE"
>3.4.1.1. Configure</A
></H3
><P
>There is a script called <B
CLASS="COMMAND"
>configure</B
> which tests your
machine, C/C++ compiler and libraries to discover what settings should work on
your system.  If you run <B
CLASS="COMMAND"
>configure</B
> with no arguments after
it, defaults will be used for all settings.  To change the settings, you can
run <B
CLASS="COMMAND"
>configure</B
> with options that override the
defaults.  You can get a list of valid configure options by typing
<B
CLASS="COMMAND"
>configure --help</B
>.  One useful configure option is
--prefix=<TT
CLASS="REPLACEABLE"
><I
>directory</I
></TT
>, which sets the directory in
which Bochs will be installed.  All the possible configure options are
documented in a <A
HREF="compiling.html#CONFIG-OPTS"
>later section</A
>.
&#13;</P
><P
>Among other things, the configure script tries to detect your platform
and which compile options to use.  If you want to control this, set these
environment variables before running configure: <CODE
CLASS="VARNAME"
>CC</CODE
>,
<CODE
CLASS="VARNAME"
>CXX</CODE
>, <CODE
CLASS="VARNAME"
>CFLAGS</CODE
>,
<CODE
CLASS="VARNAME"
>CXXFLAGS</CODE
>.  Here is an example that sets the environment
variables, using bash/ksh<A
NAME="AEN940"
HREF="#FTN.AEN940"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>
syntax:
<PRE
CLASS="SCREEN"
>  export CC=egcs
  export CXX="$CC"
  export CFLAGS="-Wall -O2 -m486 -fomit-frame-pointer -pipe"
  export CXXFLAGS="$CFLAGS"</PRE
></P
><P
>Once the configure script knows what options are selected,
it creates a Makefile in every source code directory, and creates
<TT
CLASS="FILENAME"
>$BOCHS/config.h</TT
> with all the option values written
as preprocessor #defines.  Now the sources are ready to compile.</P
><DIV
CLASS="SECTION"
><H4
CLASS="SECTION"
><A
NAME="AEN948"
>3.4.1.1.1. Configure Shortcut Scripts</A
></H4
><P
>In the Bochs source directory, you will see a series of scripts called
<TT
CLASS="FILENAME"
>.conf.<TT
CLASS="REPLACEABLE"
><I
>platform</I
></TT
></TT
>.
These scripts run the <B
CLASS="COMMAND"
>configure</B
> script for you, with a set of
options that are appropriate for that platform.  It is not necessary to
use the shortcut scripts; they are simply there to show you an example that
the developers have used. Some of these scripts have been used to build official
binary packages.

<DIV
CLASS="TIP"
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
>If a shortcut script is "almost right" for you, just edit it and then run it!
If you run a shortcut script, you don't need to run configure manually.</P
></BLOCKQUOTE
></DIV
>

Run a shortcut script using Bourne shell, like this:
<PRE
CLASS="SCREEN"
>  sh .conf.win32-vcpp</PRE
>

These <TT
CLASS="FILENAME"
>.conf.<TT
CLASS="REPLACEABLE"
><I
>platform</I
></TT
></TT
> have
been tested in recent Bochs versions:
<PRE
CLASS="SCREEN"
>  .conf.linux
  .conf.sparc
  .conf.macos
  .conf.macosx
  .conf.win32-vcpp
  .conf.win32-cygwin</PRE
></P
></DIV
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN960"
>3.4.1.2. Make</A
></H3
><P
>The <B
CLASS="COMMAND"
>make</B
> command compiles Bochs.  Make is a program
used by many software projects that reads the <TT
CLASS="FILENAME"
>Makefile</TT
> in each source
directory and follows the instructions that it finds there.  A <TT
CLASS="FILENAME"
>Makefile</TT
> tells
which files depend on which other files, what commands to use to compile and
link the code, and more.  After you have finished the configure step, just type
<B
CLASS="COMMAND"
>make</B
> to build the source code.</P
><P
>The reason that make is so popular is that it is smart about when to compile
and when not to compile.  If you run make once, it compiles every file.  But
when you run it again, it checks to see if any source files have been modified;
if not, there's nothing to do!  For example, the <TT
CLASS="FILENAME"
>Makefile</TT
> says that
<TT
CLASS="FILENAME"
>main.o</TT
> depends on <TT
CLASS="FILENAME"
>main.cc</TT
>.  Knowing
this, it will only compile <TT
CLASS="FILENAME"
>main.cc</TT
> if it is newer than
<TT
CLASS="FILENAME"
>main.o</TT
>.</P
><P
>Of course, make can only do the right thing if the <TT
CLASS="FILENAME"
>Makefile</TT
> lists all the
dependencies correctly, so human error can sometimes lead make astray.
If make refuses to build something that you think it should, or you
are getting strange compile errors, try doing <B
CLASS="COMMAND"
>make all-clean</B
>
and then <B
CLASS="COMMAND"
>make</B
> again.  All-clean means to clean up
the compiled files in every subdirectory, while <B
CLASS="COMMAND"
>make clean</B
>
means to clean up just the current directory<A
NAME="AEN978"
HREF="#FTN.AEN978"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
>.  However, it's important to note that <B
CLASS="COMMAND"
>make
all-clean</B
> leaves the configuration intact.  You do not have
to run <B
CLASS="COMMAND"
>configure</B
> again.</P
><P
>If you're really in the mood for cleaning, <B
CLASS="COMMAND"
>make dist-clean</B
>
erases all the configuration information too.  In theory, after a dist-clean
your directory should look much like when you first untarred it or checked it
out.  There's usually some extra stuff lying around, but the <TT
CLASS="FILENAME"
>Makefile</TT
> tries
at least to erase any files that it created.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN985"
>3.4.1.3. Make Install</A
></H3
><P
>Once the program has been built, the next step is typically to run
<B
CLASS="COMMAND"
>make install</B
> to copy the executables, documentation, and
other required files into a public place so that all users can use it.
By default the files are copied to some directories in /usr/local. The following
tables shows the directories and their contents.</P
><DIV
CLASS="TABLE"
><A
NAME="AEN989"
></A
><P
><B
>Table 3-5. Installed files</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><TBODY
><TR
><TD
>bin</TD
><TD
>binary executables (bochs, bximage)</TD
></TR
><TR
><TD
>lib/bochs/plugins</TD
><TD
>plugins (if present)</TD
></TR
><TR
><TD
>man/man1</TD
><TD
>manpages for installed binaries</TD
></TR
><TR
><TD
>man/man5</TD
><TD
>manpage for the config file (bochsrc)</TD
></TR
><TR
><TD
>share/bochs</TD
><TD
>BIOS images, VGABIOS images, keymaps</TD
></TR
><TR
><TD
>share/doc/bochs</TD
><TD
>HTML docs, license, readme, changes, bochsrc sample</TD
></TR
></TBODY
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1011"
>3.4.1.4. Installing the DLX Linux demo</A
></H3
><P
>To download and install the DLX Linux demo distributed with Bochs binary release
packages, use these two <B
CLASS="COMMAND"
>make</B
> commands:
<PRE
CLASS="SCREEN"
>  make unpack_dlx
  make install_dlx</PRE
>
The package will be downloaded from the Bochs website and installed at same
location as the files of the Bochs base system.</P
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="CONFIG-OPTS"
>3.4.2. Configure Options</A
></H2
><P
>This section describes the configure options for Bochs.  Perhaps the most
important option is <CODE
CLASS="OPTION"
>--help</CODE
>, since it gives you a list of all
the other options.  The configure script will detect your platform and choose
the default GUI for your platform.  If the default choice is not what you
want, use the <CODE
CLASS="OPTION"
>--with-*</CODE
> options to override the default.  The
options in the first table tell which GUI library is the default for each
platform.  Starting in version 2.0, you can use multiple
<CODE
CLASS="OPTION"
>--with-*</CODE
> options at once to compile with multiple
display libraries, and then choose between them at runtime with the
<A
HREF="bochsrc.html#BOCHSOPT-DISPLAYLIBRARY"
>display_library option</A
>
in the configuration file. Or, you can
let the configure script detect which libraries are on your system
and use them all, by configuring with <CODE
CLASS="OPTION"
>--with-all-libs</CODE
>.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>The concept of platform detection and default GUIs was added in Bochs 1.4.
In Bochs 1.3 and before, the X11 GUI was always the default.</P
></BLOCKQUOTE
></DIV
><DIV
CLASS="TABLE"
><A
NAME="AEN1026"
></A
><P
><B
>Table 3-6. Defaults by Platform</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
>Platform</TH
><TH
>Default GUI</TH
><TH
>Extra compile flags</TH
></TR
></THEAD
><TBODY
><TR
><TD
>win32, Cygwin or MinGW/MSYS</TD
><TD
>--with-win32</TD
><TD
>If using nmake method, compile using cl /nologo /MT /W3 /EHs-c- /DNDEBUG /DWIN32 /D_WINDOWS /D_CRT_SECURE_NO_WARNINGS.
    If using Visual C++ workspace, see the workspace file for compile settings.
    See <A
HREF="compiling.html#COMPILING-WIN32"
>Compiling on Win32 with Microsoft VC++</A
> for instructions.
    </TD
></TR
><TR
><TD
>MacOS X or Darwin</TD
><TD
>--with-carbon</TD
><TD
>-fpascal-strings -fno-common -arch ppc -Wno-four-char-constants -Wno-unknown-pragmas -Dmacintosh
    </TD
></TR
><TR
><TD
>MacOS 9 or before</TD
><TD
>--with-macos</TD
><TD
>none
    </TD
></TR
><TR
><TD
>AmigaOS</TD
><TD
>--with-amigaos</TD
><TD
>none
    </TD
></TR
><TR
><TD
>any other platform</TD
><TD
>--with-x11</TD
><TD
>none
    </TD
></TR
></TBODY
></TABLE
></DIV
><DIV
CLASS="TABLE"
><A
NAME="AEN1056"
></A
><P
><B
>Table 3-7. Configure Options to Select the Display Library (optional)</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><THEAD
><TR
><TH
>Option</TH
><TH
>Comments</TH
></TR
></THEAD
><TBODY
><TR
><TD
>--with-x11</TD
><TD
>Use X windows user interface.  On many operating systems,
      Bochs will use X windows by default.
       </TD
></TR
><TR
><TD
>--with-win32</TD
><TD
>Use the native Win32 GUI. This is the default on win32 platforms.
      </TD
></TR
><TR
><TD
>--with-carbon</TD
><TD
>Compile for MacOS X with the Carbon GUI.  See the
      .conf.macosx file for the correct MacOS X compile options.
      WARNING: This Bochs feature is not maintained yet and may fail.
      </TD
></TR
><TR
><TD
>--with-amigaos</TD
><TD
>Compile for Amiga MorphOS.  This code is written by Nicholai
      Benalal.</TD
></TR
><TR
><TD
>--with-rfb</TD
><TD
>        Enable support for the RFB protocol to talk to AT&amp;T's
        <A
HREF="http://www.realvnc.com/"
TARGET="_top"
>VNC Viewer</A
>.
        Refer to <A
HREF="compiling.html#COMPILE-RFB"
>Section 3.4.9</A
> for details.
      </TD
></TR
><TR
><TD
>--with-vncsrv</TD
><TD
>        Enable support for an extended RFB(VNC) GUI using the LibVNCServer library.
        Refer to <A
HREF="compiling.html#COMPILE-VNCSRV"
>Section 3.4.10</A
> for details.
      </TD
></TR
><TR
><TD
>--with-sdl</TD
><TD
>Enable support for the SDL 1.2.x GUI interface; see <A
HREF="compiling.html#COMPILE-SDL"
>Section 3.4.11</A
>.</TD
></TR
><TR
><TD
>--with-sdl2</TD
><TD
>Enable support for the SDL 2.x GUI interface; see <A
HREF="compiling.html#COMPILE-SDL2"
>Section 3.4.12</A
>.</TD
></TR
><TR
><TD
>--with-term</TD
><TD
>Use text-only gui with curses library.  Almost certainly
      won't work right with the debugger or the textconfig interface.
      </TD
></TR
><TR
><TD
>--with-macos</TD
><TD
>Use Macintosh/CodeWarrior environment.  This is for running
        configure on a platform which supports running configure, so that
        you may then transfer the configured code over to the
        real compile environment.
        WARNING: This Bochs feature is not maintained yet and may fail.
      </TD
></TR
><TR
><TD
>--with-wx</TD
><TD
>        Enable support for wxWidgets configuration and display interface;
        see <A
HREF="compiling.html#COMPILE-WX"
>Section 3.4.13</A
>.
      </TD
></TR
><TR
><TD
>--with-svga</TD
><TD
>Use SVGALIB library for Linux.  This allows a full-screen
        text and graphics display without X windows.  The SVGALIB port
        was written by Igor Popik.
        WARNING: This Bochs feature is not maintained yet and may fail.
      </TD
></TR
><TR
><TD
>--with-nogui</TD
><TD
>No native GUI; just use blank stubs.  This is if you don't
          care about having video output, but are just running tests.
      </TD
></TR
><TR
><TD
>--with-all-libs</TD
><TD
>      Automatically detect which libraries are installed on your system
      and enable them.  This option is still experimental; it might
      enable libraries that are not usable and cause the compile to fail.
      If you have trouble, just list the <CODE
CLASS="OPTION"
>--with-*</CODE
> options
      for the specific display libraries that you want.
      </TD
></TR
></TBODY
></TABLE
></DIV
><P
>The remaining options can generally be used with any GUI.  For each option
such as <CODE
CLASS="OPTION"
>--enable-cdrom</CODE
>, you can also write <CODE
CLASS="OPTION"
>--disable-cdrom</CODE
>
to explicitly turn it off. The following 3 tables show the general options
(.e.g debugger and plugins support), the CPU-related stuff (e.g. cpu level,
SMP, x86_64 support) and the devices options (e.g. PCI, USB, Cirrus graphics).</P
><DIV
CLASS="TABLE"
><A
NAME="CONFIGURE-OPTIONS-1"
></A
><P
><B
>Table 3-8. Configure Options (General)</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
>Option</TH
><TH
>Default</TH
><TH
>Comments</TH
></TR
></THEAD
><TBODY
><TR
><TD
>--enable-plugins</TD
><TD
>no</TD
><TD
>      Plugins are shared libraries that can be loaded on demand.  Example: the
      serial device is implemented as a plugin.  In Unix, the serial plugin is
      called libbx_serial.so.  When Bochs reads its configuration file, if the
      serial device is enabled it loads libbx_serial.so.  See the Features
      section for supported platforms.
      </TD
></TR
><TR
><TD
>--enable-debugger</TD
><TD
>no</TD
><TD
>        Compile in support for Bochs internal command-line debugger.  This has
        nothing to do with x86 hardware debug support.  It is a more powerful
        and non-intrusive native debugger.  Enabling this will of course slow
        down the emulation.  You only need this option if you know you need it.
        After you have run <B
CLASS="COMMAND"
>./configure</B
>, you may want to edit
        <TT
CLASS="FILENAME"
>config.h</TT
> to customize the debugger further;
        see <A
HREF="internal-debugger.html"
>Section 8.14</A
> for more information.
      </TD
></TR
><TR
><TD
>--enable-debugger-gui</TD
><TD
>yes if debugger is on</TD
><TD
>      Enable support for the gui frontend of the Bochs debugger. This feature
      is supported on Windows hosts and on hosts with GTK2 installed.
      </TD
></TR
><TR
><TD
>--enable-readline</TD
><TD
>detected by configure</TD
><TD
>      Compile the debugger with the GNU readline library, which gives
      command line editing and history.
      </TD
></TR
><TR
><TD
>--enable-gdb-stub</TD
><TD
>no</TD
><TD
>      Enable support for the remote GDB stub. See <A
HREF="debugging-with-gdb.html"
>Using Bochs and the remote GDB stub</A
>.
      NOTE: This feature cannot be used if the Bochs debugger is also enabled.
      WARNING: This Bochs feature is not maintained yet and may fail.
      </TD
></TR
><TR
><TD
>--enable-disasm</TD
><TD
>yes</TD
><TD
>Compile in support for built-in disassembler.  Bochs has
          a built-in disassembler, which is useful if you either
          run the built-in debugger (<CODE
CLASS="OPTION"
>--enable-debugger</CODE
>), or want
          disassembly of the current instruction when there is a
          panic in bochs.</TD
></TR
><TR
><TD
>--enable-docbook</TD
><TD
>detected</TD
><TD
>      Build the docbook documentation in doc/docbook.  The configure
      script will enable this option automatically if you have a program
      called docbook2html installed.
      </TD
></TR
><TR
><TD
>--enable-instrumentation=<CODE
CLASS="OPTION"
>directory</CODE
></TD
><TD
>no</TD
><TD
>      Compile in support for instrumentation.  This allows you to collect
      instrumentation data from bochs as it executes code.  You have to create
      your own instrumentation library and define the instrumentation macros
      (hooks in bochs) to either call your library functions or not, depending
      upon whether you want to collect each piece of data.
      </TD
></TR
><TR
><TD
>--enable-xpm</TD
><TD
>yes</TD
><TD
>      Enables the check for the XPM library. This option is only valid if the
      x display library is enabled (<CODE
CLASS="OPTION"
>--with-x11</CODE
>).
      </TD
></TR
><TR
><TD
>--enable-show-ips</TD
><TD
>yes</TD
><TD
>      Enables logging of measured IPS, see the <B
CLASS="COMMAND"
>ips</B
> parameter
      of the <A
HREF="bochsrc.html#BOCHSOPT-CPU-IPS"
>cpu option</A
>.
      </TD
></TR
><TR
><TD
>--enable-logging</TD
><TD
>yes</TD
><TD
>      By default, Bochs generates logfile output that can be configured with
      bochsrc options and at runtime. Use <CODE
CLASS="OPTION"
>--disable-logging</CODE
>
      to turn off this feature completely.
      </TD
></TR
><TR
><TD
>--enable-assert-checks</TD
><TD
>yes if debugger is on</TD
><TD
>      BX_ASSERT event causes a panic on assertion failure if enabled (logging
      feature must be enabled, too).
      </TD
></TR
><TR
><TD
>--enable-cpp</TD
><TD
>no</TD
><TD
>      Use .cpp as C++ suffix. Renames all the .cc files to .cpp for use with
      compilers which want that, like older MS C++ compilers. Don't use this
      option unless you know you need it.
      </TD
></TR
><TR
><TD
>--enable-idle-hack</TD
><TD
>no</TD
><TD
>      Enables Roland Mainz's experimental idle code, which is intended to
      keep Bochs from always using 100% of CPU time.  When Bochs is waiting
      around for an interrupt, the idle code uses a select() loop and some
      X11 tricks to wait until user input arrives.  This is designed to
      keep Bochs responsive while still yielding to other processes when
      Bochs is idle. It only works with X11 or term GUI.
      </TD
></TR
></TBODY
></TABLE
></DIV
><DIV
CLASS="TABLE"
><A
NAME="CONFIGURE-OPTIONS-2"
></A
><P
><B
>Table 3-9. Configure Options (CPU &amp; Memory)</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
>Option</TH
><TH
>Default</TH
><TH
>Comments</TH
></TR
></THEAD
><TBODY
><TR
><TD
><A
NAME="CONFIGURE-ENABLE-CPU-LEVEL"
></A
>--enable-cpu-level={<CODE
CLASS="OPTION"
>3,4,5,6</CODE
>}</TD
><TD
>6</TD
><TD
>      Select which CPU level to emulate.  Choices are 3,4,5,6 which mean to
      target 386, 486, Pentium, or Pentium Pro and later emulation.
      </TD
></TR
><TR
><TD
>--enable-smp</TD
><TD
>no</TD
><TD
>      Compile in support for SMP simulation.  This allows you to boot Linux and
      maybe other OSes in SMP mode, and bochs will simulate all the different
      CPUs and communication between them.  Do not expect this option to speed
      up your simulation!  On the contrary, it has to spend extra time simulating
      the different CPUs (even if they're mostly idle) and the communication
      between them. Use it to try out an SMP OS if you don't have an SMP machine,
      or to debug SMP OS drivers. Refer to <A
HREF="smp.html"
>Section 8.9</A
> for more details
      on SMP in Bochs.
      </TD
></TR
><TR
><TD
>--enable-fpu</TD
><TD
>yes</TD
><TD
>If you want to compile Bochs to make use of the FPU emulator
          written by Stanislav Shwartsman, use this option.
      </TD
></TR
><TR
><TD
>--enable-3dnow</TD
><TD
>no</TD
><TD
>3DNow! instruction set support (incomplete)</TD
></TR
><TR
><TD
>--enable-x86-64</TD
><TD
>no</TD
><TD
>      Add support for x86-64 instruction set, written by Peter Tattam and Stanislav Shwartsman.
      </TD
></TR
><TR
><TD
>--enable-vmx</TD
><TD
>no</TD
><TD
>Intel Virtualization Extensions (VMX) support</TD
></TR
><TR
><TD
>--enable-svm</TD
><TD
>no</TD
><TD
>AMD SVM (Secure Virtual Machine) extensions emulation support</TD
></TR
><TR
><TD
>--enable-avx</TD
><TD
>no</TD
><TD
>AVX instructions support</TD
></TR
><TR
><TD
>--enable-x86-debugger</TD
><TD
>no</TD
><TD
>X86 debugger support.  If the software you run in bochs
          needs to use the x86 hardware debugging facilities such as
          DR0..DR7, instruction and data breakpoints etc., then you
          should use this option.  Otherwise don't use it, as it
          will slow down the emulation.
      </TD
></TR
><TR
><TD
>--enable-monitor-mwait</TD
><TD
>no</TD
><TD
>MONITOR/MWAIT instructions support (still experimental)</TD
></TR
><TR
><TD
>--enable-alignment-check</TD
><TD
>yes if cpu level &gt;= 4</TD
><TD
>support for alignment check in the CPU and #AC exception</TD
></TR
><TR
><TD
>--enable-configurable-msrs</TD
><TD
>no</TD
><TD
>support for user configurations of emulated MSR registers
          (see example in msrs.def)</TD
></TR
><TR
><TD
>--enable-long-phy-address</TD
><TD
>no</TD
><TD
>support for guest physical address larger than 32 bit</TD
></TR
><TR
><TD
>--enable-a20-pin</TD
><TD
>yes</TD
><TD
>support for the A20 pin</TD
></TR
><TR
><TD
>--enable-large-ramfile</TD
><TD
>yes</TD
><TD
>support for guest memory larger than the host supports</TD
></TR
><TR
><TD
>--enable-repeat-speedups</TD
><TD
>no</TD
><TD
>enable support repeated I/O and memory copy speedups</TD
></TR
><TR
><TD
>--enable-fast-function-calls</TD
><TD
>no</TD
><TD
>enable support for fast function calls (gcc on x86 only)</TD
></TR
><TR
><TD
>--enable-handlers-chaining</TD
><TD
>no</TD
><TD
>enable support for handlers chaining optimization</TD
></TR
><TR
><TD
>--enable-all-optimizations</TD
><TD
>no</TD
><TD
>        Turn on the enables for all speed optimizations that the
        developers believe are safe to use:
         --enable-repeat-speedups,
         --enable-fast-function-calls,
         --enable-handlers-chaining.
      </TD
></TR
></TBODY
></TABLE
></DIV
><DIV
CLASS="TABLE"
><A
NAME="CONFIGURE-OPTIONS-3"
></A
><P
><B
>Table 3-10. Configure Options (Devices)</B
></P
><TABLE
BORDER="1"
RULES="all"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
>Option</TH
><TH
>Default</TH
><TH
>Comments</TH
></TR
></THEAD
><TBODY
><TR
><TD
>--enable-cdrom</TD
><TD
>yes</TD
><TD
>      Enable use of a real CDROM/DVD drive. The cdrom emulation and the portable
      ISO image file support are always present.  You can use this option to
      compile in support for accessing the media in your workstation's cdrom
      drive.  The supported platforms are Linux, Solaris, FreeBSD, OpenBSD,
      MacOS X and Windows. For other platforms, a small amount of code specific
      to your platform must be written.
      </TD
></TR
><TR
><TD
>--enable-sb16</TD
><TD
>no</TD
><TD
>      Enable Sound Blaster emulation. The available lowlevel sound interfaces
      are autodetected. See section <A
HREF="using-sound.html"
>Using Sound</A
>
      for supported platforms and more info. This option also enables the standard
      PC gameport which is a part of the SB16. If you don't want to use it, you
      might use <CODE
CLASS="OPTION"
>--disable-gameport</CODE
>.
      </TD
></TR
><TR
><TD
>--enable-es1370</TD
><TD
>no</TD
><TD
>      Enable ES1370 sound emulation. Just like the SB16 option, the available
      lowlevel sound interfaces are autodetected and the gameport is turned on.
      </TD
></TR
><TR
><TD
>--enable-gameport</TD
><TD
>no</TD
><TD
>      Enables the standard PC gameport. This option is only necessary if you want
      to have a gameport, but no SB16 or ES1370 (see above). The connection to a
      real joystick is currently supported on Linux and win32 only.
      </TD
></TR
><TR
><TD
>--enable-ne2000</TD
><TD
>no</TD
><TD
>Enable NE2000 network card support.  This requires a
      low-level component to be written for each OS (supported on FreeBSD,
      OpenBSD, Linux, and Windows 9x/NT/2K/XP).  When enabled and configured,
      the NE2000 device model can talk to any computer on the network
      EXCEPT FOR the local host. Exception: Under most circumstances, Bochs can
      talk to the local host on Windows, and in the ethertap interface for Linux.
      </TD
></TR
><TR
><TD
>--enable-pnic</TD
><TD
>no</TD
><TD
>Enable PCI pseudo NIC (network card) support.</TD
></TR
><TR
><TD
>--enable-e1000</TD
><TD
>no</TD
><TD
>Enable Intel(R) 82540EM Gigabit Ethernet adapter support.</TD
></TR
><TR
><TD
>--enable-clgd54xx</TD
><TD
>no</TD
><TD
>Enable Cirrus Logic GD54xx (CL-GD5430 ISA or CL-GD5446 PCI) video
      card support. For more information see <A
HREF="cirrus-notes.html"
>Section 8.20</A
>.
      </TD
></TR
><TR
><TD
>--enable-voodoo</TD
><TD
>no</TD
><TD
>Enable experimental 3dfx Voodoo Graphics emulation. The Voodoo1 is
      known to work, the Voodoo2 support is not yet complete, but almost usable.
      The Banshee / Voodoo3 support is under construction, but basicly usable.
      For more information see <A
HREF="voodoo-notes.html"
>Section 8.21</A
>.
      </TD
></TR
><TR
><TD
>--enable-iodebug</TD
><TD
>yes if debugger is on</TD
><TD
>      Dave Poirier has written an experimental interface to the debugger
      using I/O ports, so that software running in the guest OS can access
      features of the debugger.  You only want this option if you are
      developing guest OS code for use in Bochs.  In other words, most people
      don't.  Also, it should only be used with <CODE
CLASS="OPTION"
>--enable-debugger</CODE
>.
      See the <A
HREF="http://bochs.sourceforge.net/doc/docbook/development/iodebug.html"
TARGET="_top"
>      developer documentation</A
> for details.
      </TD
></TR
><TR
><TD
>--enable-pci</TD
><TD
>yes</TD
><TD
>Enable limited i440FX / i430FX / i440BX PCI support. This is still
      incomplete, but usable.
      </TD
></TR
><TR
><TD
>--enable-pcidev</TD
><TD
>no</TD
><TD
>        Enable PCI host device mapping support. This requires <CODE
CLASS="OPTION"
>--enable-pci</CODE
>
        to be set as well as Linux 2.4, 2.6 or 3.x as host.
        WARNING: This Bochs feature is not maintained yet and may fail.
      </TD
></TR
><TR
><TD
>--enable-usb</TD
><TD
>no</TD
><TD
>        Enable i440FX / i440BX PCI USB support (UHCI). The host controller with
        2-port root hub and 8 USB device types are available.
      </TD
></TR
><TR
><TD
>--enable-usb-ohci</TD
><TD
>no</TD
><TD
>        Enable USB OHCI support. The host controller with 2-port
        root hub is available (USB device types: same as UHCI).
      </TD
></TR
><TR
><TD
>--enable-usb-ehci</TD
><TD
>no</TD
><TD
>        Enable USB EHCI support. The host controller with 6-port
        root hub is available (USB device types: same as UHCI).
      </TD
></TR
><TR
><TD
>--enable-usb-xhci</TD
><TD
>no</TD
><TD
>        Enable USB xHCI support. The host controller with 4-port
        root hub is available (USB device types: same as UHCI).
      </TD
></TR
><TR
><TD
>--enable-raw-serial</TD
><TD
>no</TD
><TD
>        Enable support for the serial port emulation to access to the host's
        serial port. This feature is partly implemented for Windows hosts only.
      </TD
></TR
></TBODY
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1363"
>3.4.3. Transcript of Successful Compilation</A
></H2
><P
>This example shows the output of a compilation and installation on Linux.
<PRE
CLASS="SCREEN"
>  user$ <B
CLASS="COMMAND"
>ls -l bochs-2.5.tar.gz</B
>
  -rw-r--r-- 1 user   users 4117999 27. Nov 17:14 bochs-2.5.tar.gz
  user$ <B
CLASS="COMMAND"
>gunzip -c bochs-2.5.tar.gz | tar -xvf -</B
>
  bochs-2.5/
  bochs-2.5/.conf.sparc
  bochs-2.5/build/
  bochs-2.5/build/macosx/
  bochs-2.5/build/macosx/pbdevelopment.plist
  bochs-2.5/build/macosx/make-dmg.sh
    .
    .
    .
  bochs-2.5/memory/memory.cc
  bochs-2.5/memory/misc_mem.cc
  bochs-2.5/memory/Makefile.in
  user$ <B
CLASS="COMMAND"
>cd bochs-2.5</B
>
  user$ <B
CLASS="COMMAND"
>./configure --enable-cpu-level=6</B
>
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking target system type... x86_64-unknown-linux-gnu
  checking if you are configuring for another platform... no
  checking for standard CFLAGS on this platform...
  checking for gcc... gcc
    .
    .
    .
  config.status: creating build/win32/nsis/bochs.nsi
  config.status: creating host/linux/pcidev/Makefile
  config.status: creating config.h
  config.status: creating ltdlconf.h
  user$ <B
CLASS="COMMAND"
>make</B
>
  cd iodev &#38;&#38; \
          make  libiodev.a
  make[1]: Entering directory `/home/volker/Archiv/test/bochs-2.5/iodev'
  g++ -c  -I.. -I./.. -I../instrument/stubs -I./../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    devices.cc -o devices.o
  g++ -c  -I.. -I./.. -I../instrument/stubs -I./../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    virt_timer.cc -o virt_timer.o
  g++ -c  -I.. -I./.. -I../instrument/stubs -I./../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    slowdown_timer.cc -o slowdown_timer.o
  g++ -c  -I.. -I./.. -I../instrument/stubs -I./../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    pic.cc -o pic.o
    .
    .
    .
  echo done
  done
  /bin/sh ./libtool --mode=link g++ -o bochs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES      -DBX_SHARE_PATH='"/usr/local/share/bochs"'  -export-dynamic logio.o main.o config.o load32bitOShack.o pc_system.o osdep.o plugin.o crc.o   \
                  iodev/libiodev.a  cpu/libcpu.a cpu/cpudb/libcpudb.a \
                  memory/libmemory.a gui/libgui.a \
                  disasm/libdisasm.a   \
                  fpu/libfpu.a \
                  -lSM -lICE -lX11 -lXpm -lXrandr   \
                  \
                  \
                  \
                  \
                  -lm
  mkdir .libs
  g++ -o bochs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DBX_SHARE_PATH=\"/usr/local/share/bochs\" logio.o main.o config.o load32bitOShack.o pc_system.o osdep.o plugin.o crc.o -Wl,--export-dynamic  iodev/libiodev.a cpu/libcpu.a cpu/cpudb/libcpudb.a memory/libmemory.a gui/libgui.a disasm/libdisasm.a fpu/libfpu.a -lSM -lICE -lX11 -lXpm -lXrandr -lm
  gcc -c -I. -I./. -Iinstrument/stubs -I./instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ./misc/bximage.c -o misc/bximage.o
  /bin/sh ./libtool --mode=link g++ -o bximage -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES     misc/bximage.o
  g++ -o bximage -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES misc/bximage.o 
  gcc -c -I. -I./. -Iinstrument/stubs -I./instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES   ./misc/bxcommit.c -o misc/bxcommit.o
  /bin/sh ./libtool --mode=link g++ -o bxcommit -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    misc/bxcommit.o
  g++ -o bxcommit -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES misc/bxcommit.o 
  user$ <B
CLASS="COMMAND"
>su</B
>
  root# <B
CLASS="COMMAND"
>make install</B
>
  cd iodev &#38;&#38; \
          make  libiodev.a
  make[1]: Entering directory `/home/volker/Archiv/test/bochs-2.5/iodev'
    .
    .
    .
  for i in CHANGES COPYING README TODO; do if test -f $i; then install -m 644 $i /usr/local/share/doc/bochs; else install -m 644 ./$i /usr/local/share/doc/bochs; fi; done
  rm -f /usr/local/share/doc/bochs/README
  cat ./build/linux/README.linux-binary ./README &#62; /usr/local/share/doc/bochs/README
  install -m 644 ./.bochsrc /usr/local/share/doc/bochs/bochsrc-sample.txt
  root# <B
CLASS="COMMAND"
>exit</B
>
  user$ _</PRE
></P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILING-WIN32"
>3.4.4. Compiling on Win32 with Microsoft VC++</A
></H2
><P
>The standard compile uses the configure script, but the Windows platform
cannot run the configure script natively.
The current solution to this problem is that the Bochs
configure script must be run on a different platform that does support
shell scripts, with options that cause it to configure for a Win32
platform instead of the native one.  Many people have access to a UNIX
machine that could run the configure script, or you can use Cygwin or
MinGW/MSYS to run the configure script.
<A
NAME="AEN1378"
HREF="#FTN.AEN1378"
><SPAN
CLASS="footnote"
>[3]</SPAN
></A
>.</P
><P
>Download the Bochs sources on a machine that can run shell scripts.
Edit the configure shortcut script <TT
CLASS="FILENAME"
>.conf.win32-vcpp</TT
>
if you want to adjust the configure options.  Then type these commands
in the Bochs source directory:
<PRE
CLASS="SCREEN"
>  sh .conf.win32-vcpp
  make win32_snap</PRE
>
These commands will run the configure step, produce VC++ makefiles and
workspace files, and pack it all into a .zip file in the directory above the
source directory <A
NAME="AEN1383"
HREF="#FTN.AEN1383"
><SPAN
CLASS="footnote"
>[4]</SPAN
></A
>.  The .zip file is all ready to transfer to the target Windows
machine to be unzipped and compiled.  Or, if you run the sh/make steps in
Cygwin, you are already on the target machine so you don't need the .zip
file.</P
><P
>When you have the Win32 sources transferred to a Windows machine with VC++,
find the workspace file called <TT
CLASS="FILENAME"
>bochs.sln</TT
> in the folder
"vs2013" and load it in VC++. Choose <B
CLASS="COMMAND"
>Project:Set Active Project</B
>
and be sure that "bochs" is selected. Then choose <B
CLASS="COMMAND"
>Build:Build bochs.exe</B
>.
This will build all the required libraries (iodev, cpu, etc.) and the auxiliary
programs <TT
CLASS="FILENAME"
>bximage.exe</TT
>, <TT
CLASS="FILENAME"
>bxhub.exe</TT
> and
<TT
CLASS="FILENAME"
>niclist.exe</TT
>.</P
><P
>Using workspaces is easy and intuitive, but there is one caveat. The workspaces
come directly out of a ZIP file in <TT
CLASS="FILENAME"
>build/win32/vs2013ex-workspace.zip</TT
>,
and they are not controlled by the configure script. When you compile with certain
configure options (e.g. <CODE
CLASS="OPTION"
>--with-sdl</CODE
>) you need to link with additional
libraries. For now you must add them to the VC++ workspace by hand. In version 2.0,
we have improved the situation considerably by adding #if...#endif around every optional
file and including nearly every Bochs source file in the workspace.  This solves the
problem of having to manually add source files to the workspace when you turn
on configure options such as <CODE
CLASS="OPTION"
>--enable-debugger</CODE
>. The problem of adding
link libraries remains unresolved.</P
><DIV
CLASS="TIP"
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
>To compile with the Bochs debugger enabled, add <CODE
CLASS="OPTION"
>--enable-debugger</CODE
>
to the configure line in <TT
CLASS="FILENAME"
>.conf.win32-vcpp</TT
> before running it.
No modifications to the workspace are necessary.</P
></BLOCKQUOTE
></DIV
><P
>An alternative way to compile is to run <TT
CLASS="FILENAME"
>nmake.exe</TT
> in an
MS-DOS window.  Instead of using the workspace files, nmake uses the Bochs
makefiles that are generated by configure. The nmake method is currently used
to build the release binaries.</P
><P
>The <B
CLASS="COMMAND"
>make install</B
> doesn't work with nmake yet. Currently
it must be run inside of Cygwin or MinGW/MSYS and requires the environment
variable <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>INSTDIR</I
></SPAN
> to be set.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-CYGWIN"
>3.4.5. Compiling on Win32 with Cygwin or MinGW/MSYS</A
></H2
><P
>Cygwin is a free Unix-like environment for Windows written by
Steve Chamberlain and now maintained by RedHat, Inc.  You can download
it from <A
HREF="http://www.cygwin.com"
TARGET="_top"
>www.cygwin.com</A
>.  Because
Cygwin supports the configure script and uses GNU gcc/g++, you can use the
standard compile process.  The configure script should automatically detect
Cygwin and add "-mno-cygwin -DWIN32" to the compiler options.  You should
get a working Bochs if you just type:
<PRE
CLASS="SCREEN"
>  configure
  make</PRE
>

Optionally, you can use the configure shortcut script for Cygwin,
<TT
CLASS="FILENAME"
>.conf.win32-cygwin</TT
>, instead of running configure
directly.  If this script is close to what you need, just edit the script and
then run it.  To use the configure shortcut script and compile in Cygwin, the
commands are
<PRE
CLASS="SCREEN"
>  sh .conf.win32-cygwin
  make</PRE
>
To find out the options which are known to work in Cygwin, open the file
<TT
CLASS="FILENAME"
>.conf.win32-cygwin</TT
> in any text editor/viewer and have
a look at the end of that file.</P
><P
>When using gcc 4.7 or newer you need to add the switch <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>-mno-ms-bitfields</I
></SPAN
>
to the CFLAGS, to make sure that hdimage and network structures are packed as
expected.</P
><P
>The command <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>make install</I
></SPAN
> installs the Bochs files in the directory
structure of your build environment. To install Bochs into any desired folder you
need to use the <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>install_win32</I
></SPAN
> target. It requires the environment
variable <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>INSTDIR</I
></SPAN
> to be set.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-MACOS9-CODEWARRIOR"
>3.4.6. Compiling on MacOS 9 with CodeWarrior</A
></H2
><P
>  It is possible that this hasn't been tried since 1999. In theory, you
  run <B
CLASS="COMMAND"
>sh .conf.macos</B
> on a Unix box to build the
  makefiles and headers, copy the whole thing over to a Mac, and then
  use CodeWarrior to compile. Since it hasn't been tested in so long,
  it is quite likely that some work is needed to bring the Mac port up
  to date.</P
><P
>  If you are interested and have the required MacOS development tools, please
  let us know by contacting the <A
HREF="mailinglist.html#BOCHS-DEVELOPERS"
>bochs-developers mailing list</A
>. Someone requests a MacOS port
  almost once a month, but none of the developers know how to help them.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-MACOSX"
>3.4.7. Compiling on MacOS X</A
></H2
><P
>The port to MacOS X with Carbon API by Emmanuel Mailliard is quite new, and the
configure and makefile support was added by Bryce Denney.  You will need
the compiler and libraries from the development tools CD.  Bochs should
configure and compile with the Carbon GUI if you simply type:
<PRE
CLASS="SCREEN"
>  configure
  make</PRE
>
Optionally, you can use the configure shortcut script for MacOS X,
<TT
CLASS="FILENAME"
>.conf.macosx</TT
>, instead of running configure directly.
If this script is close to what you need, just edit the script and then
run it.  To use the configure shortcut script and compile, the commands
are
<PRE
CLASS="SCREEN"
>  sh .conf.macosx
  make</PRE
>

MacOS X has a special format for an application bundle, which looks like a
directory that contains the required resource files and binaries.  The Makefile
currently creates this application bundle "by hand" using mkdir and copy, which
is surely the wrong way to do it.  Bryce doesn't know the official way to
create an application from a Makefile, so this hack will remain until a real
Mac developer helps to clean it up.</P
><P
>On MacOS X the default GUI is the Carbon interface, but you can also try other
Bochs GUIs. Use <CODE
CLASS="OPTION"
>--with-x11</CODE
> for X windows,
<CODE
CLASS="OPTION"
>--with-rfb</CODE
> for VNC/RFB, <CODE
CLASS="OPTION"
>--with-sdl</CODE
> for SDL
or <CODE
CLASS="OPTION"
>--with-sdl2</CODE
> for SDL2.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-MORPHOS"
>3.4.8. Compiling on Amiga/MorphOS</A
></H2
><P
>  Nicholai Benalal created this port to MorphOS running on Amiga. It should
  compile with:
<PRE
CLASS="SCREEN"
>  configure
  make</PRE
>
  If the platform is not detected properly, you might need to use
  <CODE
CLASS="OPTION"
>--enable-amigaos</CODE
> as a configure option. Optionally, you
  can use the configure shortcut script, <TT
CLASS="FILENAME"
>.conf.amigaos</TT
>.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-RFB"
>3.4.9. Compiling with the RFB interface</A
></H2
><P
>  The RFB code was written by Don Becker <CODE
CLASS="EMAIL"
>&#60;<A
HREF="mailto:x-odus@iname.com"
>x-odus@iname.com</A
>&#62;</CODE
>,
  who has a Bochs-RFB web page on his site,
  <A
HREF="http://www.psyon.org/bochs-rfb/"
TARGET="_top"
>http://www.psyon.org/bochs-rfb/</A
>.</P
><P
>  This interface allows you to view the Bochs display with
  AT&amp;T's <A
HREF="http://www.realvnc.com/"
TARGET="_top"
>VNC Viewer</A
>.
  The protocol used between a VNC server and a VNC viewer is called RFB.
  Because the RFB code in Bochs is written with portable network socket
  and POSIX thread code, it can be compiled on many platforms and has
  been tested in Linux and Win32. No additional libraries are required.
  To try it, type:
<PRE
CLASS="SCREEN"
>  configure --with-rfb
  make</PRE
>
  RFB currently uses this setup:
<P
></P
><UL
><LI
><P
>port range 5900 to 5949 (using the first one available)</P
></LI
><LI
><P
>no authentification</P
></LI
><LI
><P
>by default 30 seconds waiting for client</P
></LI
><LI
><P
>8 bpp (BGR233) supported only</P
></LI
><LI
><P
>if client doesn't support resize: desktop size 720x480 (for text mode and standard VGA)</P
></LI
><LI
><P
>if resize supported: maximum resolution 1280x1024</P
></LI
></UL
></P
><P
>With the display library option "timeout" the default value of 30 seconds can
be changed. With a value of 0 it is possible to start the simulation without a
client connected.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-VNCSRV"
>3.4.10. Compiling with the VNCSRV interface</A
></H2
><P
>  The <A
HREF="http://libvnc.github.io/"
TARGET="_top"
>LibVNCServer</A
> is
  a cross-platform library that allows to implement VNC server functionality easily.
  On platforms supported by LibVNCServer Bochs can be compiled with support for
  it this way:
<PRE
CLASS="SCREEN"
>  configure --with-vncsrv
  make</PRE
></P
><P
>Unlike the RFB GUI this new implementation is not limited to 8 bpp and it is
possible to connect a Bochs session with a web browser.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-SDL"
>3.4.11. Compiling with the SDL interface</A
></H2
><P
>  Dave Poirier has written an SDL interface for Bochs. Simple DirectMedia
  Layer, or SDL, is a cross-platform multimedia library distributed from
  <A
HREF="http://libsdl.org/"
TARGET="_top"
>libsdl.org</A
>. SDL is available
  for many platforms including Win32, Linux, BSD, IRIX, MacOS, MacOS X,
  and AmigaOS.</P
><P
>  To compile Bochs with SDL, you must first install the SDL library
  from <A
HREF="http://libsdl.org/"
TARGET="_top"
>libsdl.org</A
>. You
  can either get the source code and compile it yourself, or install
  the development libraries for your platform (already compiled).
  Then, go into the Bochs directory and type:
<PRE
CLASS="SCREEN"
>  configure --with-sdl
  make</PRE
></P
><P
>  If you are on FreeBSD and have SDL installed using the ports collection, Bochs
  won't be able to find the library automatically, as the SDL config script is
  called <TT
CLASS="FILENAME"
>sdl11-config</TT
> in that case (even for version 1.2).
  The easiest way to make Bochs find it, is to create a symlink to that script
  called <TT
CLASS="FILENAME"
>sdl-config</TT
> inside a directory which is in the path.
  For example:
<PRE
CLASS="SCREEN"
>  ln -s /usr/local/bin/sdl11-config ~/bin/sdl-config</PRE
></P
><P
>To compile in Microsoft VS2013Ex, you have to configure on a different system
(see <A
HREF="compiling.html#COMPILING-WIN32"
>Compiling on Win32 with Microsoft VC++</A
>).
Before running the configure script, you have to add <CODE
CLASS="OPTION"
>--with-sdl</CODE
>
to the shortcut script. If you have already configured, you can set <B
CLASS="COMMAND"
>BX_WITH_SDL</B
> to 1 in <TT
CLASS="FILENAME"
>config.h</TT
>.</P
><P
>Then you have to set up the project for SDL this way:
<PRE
CLASS="SCREEN"
>- add source file <TT
CLASS="FILENAME"
>sdl.cc</TT
> to the module <B
CLASS="COMMAND"
>gui</B
>
- add path to the SDL include files to the modules <B
CLASS="COMMAND"
>bochs</B
> and <B
CLASS="COMMAND"
>gui</B
>
- add lbraries <TT
CLASS="FILENAME"
>SDL.lib</TT
> and <TT
CLASS="FILENAME"
>SDLmain.lib</TT
> to the module <TT
CLASS="FILENAME"
>bochs</TT
>
- change the runtime library for all modules to <B
CLASS="COMMAND"
>Multithreaded-DLL (/MD)</B
></PRE
>
Compiling with MSVC <B
CLASS="COMMAND"
>nmake</B
> is not supported yet.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-SDL2"
>3.4.12. Compiling with the SDL version 2 interface</A
></H2
><P
>The SDL library version 2 is now also supported by Bochs. For some basic information
about SDL, see <A
HREF="compiling.html#COMPILE-SDL"
>Section 3.4.11</A
>. The configure option to enable SDL2
support is <CODE
CLASS="OPTION"
>--with-sdl2</CODE
> and the configuration script is called
<B
CLASS="COMMAND"
>sdl2-config</B
>. Note that the Bochs guis for SDL version 1.2.x
and 2.x are mutually exclusive. The legacy SDL gui support will be removed someday.
When using the gui library autodetection (<CODE
CLASS="OPTION"
>--with-all-libs</CODE
>) the
configure script probes for SDL version 2 first.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="COMPILE-WX"
>3.4.13. Compiling with the wxWidgets interface</A
></H2
><P
>  wxWidgets is a cross-platform C++ user interface library which
  you can download for free at <A
HREF="http://wxwidgets.org/"
TARGET="_top"
>wxwidgets.org</A
>.
  The wxWidgets port of Bochs provides both a graphical configuration interface for
  editing <TT
CLASS="FILENAME"
>bochsrc</TT
> options (see
  <A
HREF="bochsrc.html#BOCHSOPT-CONFIGINTERFACE"
>config_interface option</A
>) and a
  display (see <A
HREF="bochsrc.html#BOCHSOPT-DISPLAYLIBRARY"
>display_library option</A
>).
  It was written by Bryce Denney, Don Becker, Dave Poirier, and Volker Ruppert.
<PRE
CLASS="SCREEN"
>  configure --with-wx
  make</PRE
></P
><P
>  If you want Bochs to use a wxWidgets installation not in your path (but installed
  somewhere else), you need to set the WX_CONFIG environment variable to the
  proper wx-config script, before running configure (example for csh):
<PRE
CLASS="SCREEN"
>  setenv WX_CONFIG '/home/compile/wx/bin/wx-config'</PRE
></P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1516"
>3.4.14. Building an RPM on Linux</A
></H2
><P
>RPM stands for "RedHat Package Manager."  An RPM is a compressed file
containing files to be installed on your system.  Bochs
has a special shell script called <TT
CLASS="FILENAME"
>make-rpm</TT
> that helps
to build an RPM of Bochs.  Start with a clean source directory.  Edit
.conf.linux first if you want to adjust the configure options.
Then, type:

<PRE
CLASS="SCREEN"
>  ./build/redhat/make-rpm | tee /tmp/build.txt</PRE
>

When this command completes, you should have a source RPM and a binary RPM of
Bochs in the current directory.  The <B
CLASS="COMMAND"
>tee</B
> part of the
command (optional) saves a transcript of the build process into /tmp/build.txt,
which is very useful if anything goes wrong.  Instructions for installing an
RPM are <A
HREF="install-binary.html#LINUXRPM"
>here</A
>.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>In the past, you had to build rpms as root, but as of version 2.0 you can build
them as a normal user.</P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN1525"
>3.4.15. Compile Problems</A
></H2
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1527"
>3.4.15.1. The configure script failed</A
></H3
><P
>The <B
CLASS="COMMAND"
>configure</B
> script can fail for various reasons. If the error
message on the shell doesn't give enough information, it is recommended to review
the output file <TT
CLASS="FILENAME"
>config.log</TT
> to find out what exactly
happened. The following issues can be fixed by modifying the configure options used:
<P
></P
><UL
><LI
><P
>deprecated option (option from previous Bochs version not needed /
  supported anymore)</P
></LI
><LI
><P
>mutually exclusive option (e.g. <CODE
CLASS="OPTION"
>--enable-debugger</CODE
> and <CODE
CLASS="OPTION"
>--enable-gdb-stub</CODE
>)</P
></LI
><LI
><P
>dependent option (e.g. USB support requires PCI support)</P
></LI
><LI
><P
>incomplete option (e.g. <CODE
CLASS="OPTION"
>--enable-cpu-level</CODE
> requires an argument)</P
></LI
><LI
><P
>development package for library not installed (e.g. for <CODE
CLASS="OPTION"
>--with-wx</CODE
>)</P
></LI
></UL
>
If the configure issue cannot be fixed by option changes and / or installing
development packages / tools it should be reported in the <A
HREF="mailinglist.html#BOCHS-DEVELOPERS"
>bochs-developers mailing list</A
> or the <A
HREF="feedback-support.html#SF-TRACKERS"
>SF bug
tracker</A
> for the Bochs project.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1549"
>3.4.15.2. Make / compilation failure</A
></H3
><P
>The <B
CLASS="COMMAND"
>make</B
> utility itself can only fail if the specified target
is not supported by the environment or simply doesn't exist. In most cases the programs
called from <B
CLASS="COMMAND"
>make</B
> are causing the failure (e.g. compiler / linker).</P
><P
>In some cases it might be useful to rebuild Bochs completely by calling
<B
CLASS="COMMAND"
>make dist-clean</B
> and running the <B
CLASS="COMMAND"
>configure</B
>
script once again. These steps are recommended if the development sources from
SVN are used and one of the build system files (e.g. <TT
CLASS="FILENAME"
>Makefile</TT
>
or <TT
CLASS="FILENAME"
>config.h.in</TT
>) has been changed.</P
><P
>Sometimes it is possible to isolate the failing piece of code by disabling one or
more configure options. For example, if the compilation fails somewhere in the cpu/avx*
files, it might help to configure without <CODE
CLASS="OPTION"
>--enable-avx</CODE
>. The same
could be done with other Bochs facilities controlled by configure options.</P
></DIV
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="AEN1561"
>3.4.15.3. Runtime issues with self-compiled Bochs</A
></H3
><P
>After a successful compilation the self-compiled Bochs can fail if at least one
library is not installed properly. This can happen if the library consists of a
development and a runtime package and the second one is missing. Another problem
can appear on build environments like Cygwin and MinGW/MSYS. Applications built
there are usually designed to be run inside of the environment. When starting
them from the Windows shell, it may cause errors like "missing <TT
CLASS="FILENAME"
>cygwin1.dll</TT
>"
or similar. In that case, the missing DLL must be copied from e.g. the Cygwin folder
to the location of the compiled EXE file.</P
></DIV
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN940"
HREF="compiling.html#AEN940"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The syntax for bash and ksh is given.  In csh and variants, use the syntax
<B
CLASS="COMMAND"
>setenv <TT
CLASS="REPLACEABLE"
><I
>VARIABLE</I
></TT
>
<TT
CLASS="REPLACEABLE"
><I
>value</I
></TT
></B
> to change environment variables.
Do not use an equal sign for csh!</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN978"
HREF="compiling.html#AEN978"
><SPAN
CLASS="footnote"
>[2]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>This is different from the terminology of some other projects, and it may cause
confusion.  Sometimes "clean" implies that all subdirectories are affected.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1378"
HREF="compiling.html#AEN1378"
><SPAN
CLASS="footnote"
>[3]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Because Bochs depends so much on the configure script, if you are doing
much win32 Bochs development, you should consider downloading Cygwin or
MinGW/MSYS so that you can run the configure step natively.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN1383"
HREF="compiling.html#AEN1383"
><SPAN
CLASS="footnote"
>[4]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>If the source directory is <TT
CLASS="FILENAME"
>/home/joe/bochs-win32</TT
>, the
resulting .zip file is in <TT
CLASS="FILENAME"
>/home/joe/bochs-win32-msvc-src.zip</TT
>.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="install-binary.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="setup.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Installing a Binary</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="installation.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Setup</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>